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Chapter 1 

Introduction 


It is no doubt every programmer's dream that each program he or she writes, no matter in what 
language, could be submitted to another program which would determine whether the given 
program was correct or not, thereby freeing the programmer from the laborious task of program 
testing. A denunciation of program testing as a means of demonstrating program correctness 
is given by Edsger Dijkstra, a passionate proponent of the use of formal methods in Computer 
Science: 

“Program testing can be used to show the presence of bugs, but never to show their 
absence.'f 

Thus, the ultimate goal of program verification is to overcome this “fallacy of debugging" by 
providing a mechanical means (i.e. a computer program) for proving mathematically whether a 
given program is correct or not. 

There are at least two major problems in attaining this goal. The first is that a program can only 
be shown to be correct with respect to a precise specification of what the program is supposed to 
do, something which is difficult to define formally for non-trivial programs. The second problem, 
apparently more serious than the first, is that it is not possible, in general, to write a program which 
checks the correctness of any program submitted to it; in other words, the problem is undecidable . 

We shall consider each of these problems in more detail later. Before doing so, it is important 
to realise that the usebf formal methods, such as mathematical logic, both to verify the correctness 
of programs and as a methodology for constructing correct programs is a controversial topic. To 
illustrate this, some comments from a recent debate on the subject £re quoted below 1 . 

The debate arose from reaction to a talk titled “On the Cruelty of Really Teaching Computer 
Science" given at the ACM Computer Science Conference in February 1988 by Dijkstra. The 
principal theme of his talk was that “computers represent a radical novelty... that has no precedent 
in our history." In his opinion, a consequence of this is that 

“... frantic efforts at hiding or denying the frighteningly unfamiliar... have been 
bundled under the name “Software Engineering” ... [which] should be known as 
“The Doomed Discipline”.” 

After slating a number of Software Engineering techniques, Dijkstra gives his solution for over¬ 
coming this radical novelty: 

“I propose that we adopt for computing science VLSAL (Veiy Large Scale Appli¬ 
cation of Logic). ... I expect computing science to transcend its parent disciplines, 
mathematics and logic." 

He concludes by describing his view of of an introductory programming course: 

'The quotations are taken from “A Debate on Teaching Computer Science” which appeared in Communications of 
the ACM, Vol. 32, No. 12 (Dec. 1989), pp. 1397-1414. 
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“On the one hand, we teach what looks like predicate calculus.... On the other hand, 

we teach a simple, clean, imperative programming language.we stress that 

the programmer’s task is not just to write down a program, but that his main task is to 
give a formal proof that the program he proposes meets the equally formal functional 
specification. ... Finally, in order to drive home the message that this introductoiy 
programming course is primarily a course in formal mathematics, we see to it that the 
programming language in question has not been implemented on campus ... 

A less radical view is taken by David Pamas who, among other things, has been an outspoken 
critic of the claims made by the Strategic Defense Initiative (SDI)—better known as “Star Wars”— 
in the United States. He takes exception to Dijkstra’s dismissal of Software Engineering with 
some enlightening analogies with tradition engineering disciplines. 

‘‘Most introductoiy engineering texts define an engineer as one who uses science 
and mathematics to produce useful products. ... The fact that some people write 
poor papers and textbooks under the title “software engineering” does not justify 
abandonment of the hope that, some day, programs will be produced by properly 
educated professional engineers. ... Good engineering programs emphasize the 
use of formal methods in exactly the way suggested by Dijkstra. ... However, an 
engineering education also teaches students to understand the limits of mathematical 
models.” 

It is in this spirit that we wish to address the subject of program verification. Although it has 
its limitations, there are a number of practical benefits to be gained through using its techniques, 
such as, 

• promoting better programming discipline, 

• reducing programming errors, 

• reducing testing time, and 

• improving documentation. 

For these reasons, program verification is usually viewed as an integral component of Software 
Engineering. 

1.1 A Motivating Scenario 

The following “stoiy” is taken from the book by Gries [4]. 

We have just finished writing a large program. Among other things, the program computes as 
intermediate results the quotient q and remainder r arising from dividing a non-negative integer 
x by a positive integer y. For example, with x = 7 and y = 2, the program calculates q = 3 
(since 7 4- 2 = 3) and r = 1 (since the remainder when 7 is divided by 2 is 1). 

Our program appears below, with dots “... ” representing the parts of the program that precede 
and follow the remainder-quotient calculation. The calculation is performed as given because the 
program will sometimes be executed on a processor that has no integer division, and portability 
must be maintained at all costs! The remainder-quotient calculation actually seems quite simple; 
since -r cannot be used, we have elected to subtract divisor y from a copy of x repeatedly, keeping 
track of how many subtractions are made, until another subtraction would yield a negative integer. 

r := x; q := 0; 

WHILE r > y DO 

BEGIN r:=r-y;q:=q+l END; 
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We’re ready to debug the program. With respect to the remainder-quotient calculation, we’re smart 
enough to realize that the divisor should initially be greater than 0 and that upon its termination 
the variables should satisfy the formula 


x = y * q + r, 

so we add some output statements to check the calculations: 


write ('dividend x =', x, 'divisor y =', y); 
r := x? q := 0; 

WHILE r > y DO 

BEGIN r := r - y; q := q + 1 END; 
write ('y*q+r =', y*q+r)? 


Unfortunately, we get voluminous output because the program segment occurs in a loop, so our 
first test run is wasted. We try to be more selective about what we print Actually, we need to 
know values only when an error is detected. Having heard of a new feature just inserted into the 
compiler, we decide to try it. If a Boolean expression appears within braces { and } at a point in 
the program, then, whenever “flow of control” reaches that point during execution, it is checked: 
if false, a message and a dump of the program variables are printed; if true, execution continues 
normally. These Boolean expressions are called assertions , since in effect we are asserting that 
they should be true when flow of control reaches them. The systems people encourage leaving 
assertions in the program, because they help document it. 

Protests about inefficiency during production runs are swept aside by the statement that there 
is a switch in the computer to turn off assertion checking. Also, after some thought, we decide it 
may be better always to check assertions—detection of an error during production would be well 
worth the extra cost. 

So we add assertions to the program: 

{»> 0 } 

r ;= x; q := 0; 

(1) WHILE r > y DO 

BEGIN r :=r -y; q := q + 1 END; 

{x = y*q + r) 


Testing now results in far less output, and we make progress. Assertion checking detects an error 
during a test run because y is 0 just before a remainder-quotient calculation, and it takes only four 
hours to find the error in the calculation of y and fix it. 

But then we spend a day tracking down an error for which we received no nice false-assertion 
message. We finally determine that the remainder-quotient calculation resulted in 

x = 6, y - 3,g = 1, r = 3. 

Sure enough, both assertions in (1) are true with these values; the problem is that the remainder 
should be less than the divisor, and it isn’t. We determine that the loop condition should be r > 
y instead of r > y. If only the result assertion were strong enough—if only we had used the 
assertion x = y*q + TAr < y —we would have saved a day of work! Why didn’t we think of it? 

We fix the error and insert the stronger assertion: 

*{» > 0 } 

r := x; q := 0; 
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WHILE r > y DO 

BEGIN r := r - y; q := q + 1 END; 

{x = y + q + r A r < y) 

Things go fine for a while, but one day we get incomprehensible output. It turns out that the 
quotient-remainder algorithm resulted in a negative remainder r = -2. But the remainder 
shouldn’t be negative! And we find out that r was negative because initially x was -2. Ahhh, 
another error in calculating the input to the quotient-remainder algorithm—x isn’t supposed to be 
negative! But we could have caught the error earlier and saved two days searching, in fact we 

should have caught it earlier; all we had to do was make the initial and final assertions for the 

program segment strong enough. Once more we fix an error and strengthen an assertion: 

{0 < x A 0 < y) 
r := x; q := 0; 

WHILE r > y DO 

BEGIN r :=r - y; q := q + 1 END; 

{x = y*q + rA0<r<y} 

It sure would be nice to be able to invent the right assertions to use in a less ad hoc fashion. Why 
can’t we think of them? Does it have to be a trial-and-error process? Part of our problem here 
was carelessness in specifying what the program segment was to do—we should have written the 
initial assertion (0 < x A 0 < y) and the final assertion (x = y *q + r A 0 < r < y) before 
writing the program segment, for they form the definition of quotient and remainder. 

But what about the error we made in the condition of the while loop? Could we have prevented 
that from the beginning? Is there a way to prove, just from the program and assertions, that the 
assertions are true when flow of control reaches them? Let’s see what we can do. 

Just before the loop it seems that part of our result, 

(2) x = y * q + r 

holds, since x — r and q = 0. And from the assignments in the loop body we conclude that if (2) 
is true before execution of the loop body then it is true after its execution, so it will be true just 
before and after every iteration of the loop. Let's insert it as an assertion in the obvious places, 
and let's also make all assertions as strong as possible: 

{0 < x A 0 < y} 
r ;= x; q ; = 0; 

{0 < r A 0 < y A x = y*q + r] 

WHILE r > y DO 

BEGIN {0 < r A 0 < y < r A x = y * q + r} 
r :=r - y; q := q + 1 
{0 < r A 0 < y A x = y*q-h r} 

END; 

{0 < r < y A x = y*q + r} 

Now, how can we easily determine a correct loop condition, or, given the condition, how can we 
prove it is correct? When the loop terminates the condition is false. Upon termination we want 
r < y, so that the complement, r > y must be the correct loop condition. How easy that was! 

It seems that if we knew how to make all assertions as strong as possible and if we learned 
how to reason carefully about assertions and programs, then we wouldn’t make so many mistakes, 
we would know our program was correct, and we wouldn’t need to debug programs at all! Hence, 
the days spent running test cases, looking through output and searching for errors could be spent 
in other ways. 
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1.1.1 Discussion 

The stoiy suggests that assertions, or simply Boolean expressions, are really needed in program¬ 
ming. But it is not enough to know how to write Boolean expressions; one needs to know how to 
reason with them: to simplify them, to prove that one follows from another, to prove that one is 
not true in some state, and so forth. And, later on, we will see that it is necessary to use a kind of 
assertion that is not part of the usual Boolean expression language of C++, Pascal or FORTRAN, 
the “quantified” assertion. 

Knowing how to reason about assertions is one thing; knowing how to reason about programs 
is another. In the past 10 years, computer science has come a long way in the study of proving 
programs correct. We are reaching the point where the subject can be taught to undergraduates, or 
to anyone with some training in programming and the will to become proficient. More importantly, 
the study of program correctness proofs has led to the discovery and elucidation of methods for 
developing programs. Basically, one attempts to develop a program and its proof hand-in-hand, 
with the proof ideas leading the way! If the methods are practised with care, they can lead to 
programs that are free of errors, that take much less time to develop and debug, and that are much 
more easily understood (by those who have studied the subject). 

Abpve, we mentioned that programs could be free of errors and, in a way, we implied that 
debugging would be unnecessary. This point needs some clarification. Even though we can 
become more proficient in programming, we will still make errors, even if only of a syntactic 
nature (typos). We are only human. Hence, some testing will always be necessary. But it should 
not be called debugging, for the word debugging implies the existence of bugs, which are terribly 
difficult to eliminate. No matter how many flies we swat, there will always be more. A disciplined 
method of programming should give more confidence than that! We should run test cases not to 
look for bugs, but to increase our confidence in a program we are quite sure is correct; finding an 
error should be the exception rather than the rule. 

1.2 Assertions in C 

Consider the following C program whidfcdetermines the maximum of three given integers: 

fiinclude <stdio.h> 

#include <assefct.h> 

#define TRUE 1 

main() 

{ 

int i, j, k, m? 

printf("Please enter 3 integers\n"); 

scanf("%d%d%d", &i, &j, &k) ? 

assert(TRUE)? 

if (i <= j) 
if (j < k) 
m = k? 
else 

m = j; 

else 

if (i < k) 
m = k; 
else 

m = i; 

assert( m >= i && m > j && m >= k ); 
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printfCThe maximum of %d, %d and %d is %d\n" / i, j, k, m) ; 

} 

The assert macro is available as part of the standard C library under most operating systems. 
This macro verifies a program assertion by putting diagnostics into a program. The syntax is 
assert ( expression ). If expression is false (zero), then assert writes the following message 
on the standard error output and aborts the program: 


Assertion failed: expression, file filename, line linenum 



DNDEBUG or control statement #def ine ndebug before #include <assert. h>. 


A successful execution of the above program is given below (program output, is in typewriter 
font, while user input is in italics). 

Please enter 3 integers 

123 

The maximum of 1, 2 and 3 is 3 
On the other hand, if we enter the integers 1,3,2, the following execution results. 

Please enter 3 integers 

132 

Assertion failed: m >= i && m > j && m >= k , file nonloop.c, line 22 

Abort or IOT trap - core dumped 

In this case, the program is correct while the assertion itself is wrong; the middle term should 
bem >= j. In other words, the programmer has provided an incorrect specification of what the 
program does. From a program maintenance point of view, this is perhaps an even more serious 
error than a programming error. 

So assertions as supplied by the C compiler do not contribute at all to proving that a program ^ 

is correct They do, however, provide a means of specifying conditions that are expected to be 
true of the program variables and help in program testing. 


13 A Simple Programming Language 

For our purposes, we will consider a very simple programming language containing only assign¬ 
ment statements, while loops, and conditional (if-then-else) statements. This will allow us to 
concentrate on the principles of program correctness without getting bogged down in the detailed 
syntax of a full-blown programming language. At the same time, it should be noted that such a 
simple language still has the power to express any computable function. 

The syntax of the language follows. Symbols such as v, x and y are used to denote arbi¬ 
trary program variables , S and 5, denote program statements , and C and C, denote conditional 
expressions. 


Assignment Statement 
v := e 


The state (of the program variables) is changed by assigning the value of expression e to the 
variable v . For example. 
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x ;= x + 1; 

adds one to the value of the variable x. 



The statements S \,..., S n are executed sequentially in the given order. For example, 
t := x; x := y; y := t; 

exchanges the values of variables x and y using t as a temporary variable. Notice that this 
statement has the side effect of changing the value of the variable t to the old value of x. 

One-Sided Conditional 
IF C THEN S 

If the condition C is true in the current state (of the program), then statement S is executed. If C 
is false, nothing is done. For example, in 

IF (x <> 0) THEN r := y DIV x; 

w 

r is assigned the result of dividing the value of y by the value of x if the value of x is not zero. 



If the condition C is true in the current state (of the program), then statement Si is executed. If C 
is false, then Si is executed. For example, in 

IF (x <> y) THEN max := y ELSE max := x; 

the value of the variable max is set to the maximum of the values of x and y. 

While-Loop 


WHILE C DO S 
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If the condition C is true in the current state (of the program), then statement S is executed and 
the WHlLE-statement is repeated. If C is false, nothing is done. Thus 5 is repeated executed until 
the value of C becomes true. If C never becomes £ue, then the execution of the command never 
terminates. For example, in Aifsv 

WHILE (x <> 0) DO x := x-2? 

the value of x will be repeatedly decremented by 2 if the old value of x is non-zero. The statement 
will terminate (with x having value 0) if the original value of x is an even non-negative number. 
In any other state, it will not terminate. < 

In addition to the above syntax, the keywords BEGIN and end are used to delimit compound 
statements. As an example, the program to compute the quotient and remainder after dividing one 
integer by another given in Section 1.1 is repeated below. 

r := x; q := 0; 

WHILE r > y DO 

BEGIN r := r - y; q := q + 1 END; 

On each iteration of the loop, the compound statement r := r - y; q := q + 1 is exe¬ 
cuted. 

Having defined our programming language, we now consider how we might specify what a 
particular program is expected to do, in order that we can prove that the program is correct. 


1.4 Program Specifications 

Given a program S (for example in the language of the previous section) along with conditions P 
and Q defined on the variables of 5, the notation 

{P}S{Qh 

is called a partial correctness specification. The condition P is called its precondition and 
condition Q is called its postcondition. This notation was introduced by Tony Hoare in [1]. 

Conditions on program variables will be written using standard mathematical notations to¬ 
gether with logical operators like A (‘and’), V (‘or’), -< (‘not’) and => (‘implies’)- These are 
described further in Chapter 2. 

We say that {P} S {Q} is true, if whenever S is executed in a state satisfying P and if the 
execution of S terminates, then the state in which S’s execution terminates satisfies Q. 

Example 1.4.1 Consider the specification 

{x = l}x := x + l{x = 2}. 

Here P is the condition that the value of x is 1, Q is the condition that the value of x is 2, and S 
is the assignment statement x := x+1. Specification {x = 1} x := x+1 {x = 2} is clearly 
true. □ 

These specifications are ‘partial’ because for {P} S {(?} to be true it is not necessary for the 
execution of S to terminate when started in a state satisfying P. It is only required that if the 
execution terminates, then Q holds. 

A stronger kind of specification is a total correctness specification. There is no standard 
notation for such specifications. We shall use [P] S [Q]. A total correctness specification [P] S [Q] 
is true if and only if the following conditions apply: 

1. Whenever S is executed in a state satisfying P, then the execution of S terminates. 
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2. After termination, Q holds. 

The relationship between partial and total correctness can be informally expressed by the equation: 

Total correctness = Termination + Partial correctness. 

Total correctness is what we are ultimately interested in, but it is usually easier to prove it by 
establishing partial correctness and termination separately. 

Termination is often straightforward to establish, but there are some well-known examples 
where it is not. For example, no one knows whether the program below terminates for all values 
ofx: 


WHILE x > 1 DO 

IF ODD (x) THEN x := (3 X x)+l ELSE x := x DIV 2 

(The expression x DIV 2 evaluates to the result of rounding down to x/2 to a whole number). 

We spend most of our time dealing only with partial correctness. Theories of total correctness 
can be found in the texts by Dijkstra [7] and Gries [4]. 

1.4.1 Some examples 

The examples below illustrate various aspects of partial correctness specification. 

In Examples 5,6 and 7 below, “frwe” is the condition that is always true. In Examples 3,4 and 
7, “A” is the logical operator ‘and*, i.e. if Pi and Pi are conditions, then Pi A Pi is die condition 
that is true whenever both P\ and Pi hold. 

1. {i = 1} y := x {j/= 1} 

This says that if the statement y : = x is executed in a state satisfying the condition x = 1 (i.e. 
a state in which the value of x is 1), then, if the execution terminates (which it does), then the 
condition y = 1 will hold. Clearly this specification is true. 

2. {z= 1} y := x {y = 2} 

/ 

This says that if the execution of y : = x terminates when started in a state satisfying x = 1, 
then y = 2 will hold. This is clearly false. 

3. {i = *o A y = j/o} BEGIN t := x; x := y; y := t END {x = y 0 A y = xo) 

This says that if the execution of BEGIN t := x; x := y; y := t END terminates 
(which it does), then the values of x and y are exchanged. The variables xo and yo> which 
don't occur in the statement and are used to name the initial values of program variables x and y, 
are called auxiliary variables (or ghost variables). 

4 . {x = xo A y = yo} BEGIN x : = y; y := x END {x = y Q /\y = xo} 

This says that BEGIN x : = y; y : = x END exchanges the values of x and y. This is not 
true. 


5 . {true} S {(?} 

This says that whenever S halts, Q holds. 

6. {P} S {true} 
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This specification is true for every condition P and every statement S (because true is always 
true). 


7. {true} 

BEGIN 
r := x; 

Q 0; 

WHILE y < r DO 

BEGIN r :=r - y; q := q + 1 END 
END j 

{r <y A x = r + (yxg)} 

This specification is {true} S {r < y A x = r + (y x q)} where S is the compound statement 
above. The specification is true if whenever the execution of S halts, then q is the quotient and 
r is the remainder resulting from dividing y into x. It is true (even if x is initially negative). 
Compare this to the example in Section 1.1. 

In this example a program variable q is used. This should not be contused with the Q used 
in 5 above. The program variable q ranges over numbers, whereas the postcondition Q ranges 
over conditions. In general, we use lower-case letters for particular program variables and upper¬ 
case letters in italic font for variables ranging over conditions. Preconditions, postconditions and 
assertions in general will be in italic font, whereas program statements will be in typewriter 
font. Although this subtle use of fonts might appear confusing at first, once you get the hang of 
things the difference between variables and statements will be clear (indeed you should be able to 
disambiguate things from context without even having to look at the font). 


Chapter 2 

A Taste of Logic 


In order to make statements about conditions on the program variables that we believe to be true 
at various points in a program, as well as to be able to deduce what other conditions must be true 
as a result, we need to endure a brief excursion into some of the formalities of predicate calculus. 
Before doing so, however, we consider the simpler system of propositional calculus. 

2.1 The Propositional Calculus 

Propositional calculus is a simple language for expressing formal proofs. Its primaiy constituents 
are propositions, that is, sentences that are either true or false; there are no variables in a proposition 
that make it true for some values of the variables and false for others. The propositional calculus 
is essentially a formalisation of the logical operators tabulated below. 

-i not (negation) 

A and (conjunction) 

V or (disjunction) 

=> implies (if... then) 

& if and only if 

i 

We introduce some of the terminology by means of an example in English. Consider the 
following argument. 

1. If Superman were able and willing to prevent evil, he would do so. 

2. If he were unable to prevent evil, he would be impotent. 

3. If he were unwilling to prevent evil, he would be malevolent. 

4. Superman does not prevent evil. 

5. If Superman exists, he is neither impotent nor malevolent. 

6. Therefore Superman does not exist. 

Items (1) to (5) above are called the premises of the argument, while (6) is the conclusion . We 
are concerned with whether or not the conclusion logically follows from the premises. If so, the 
argument is logical or valid. 

We can decompose the argument into propositions which are combined by means of the 
logical connectives given above. The individual propositions, each assigned a unique symbol, are 
as follows: 


11 



12 


** CHAPTER 2. A TASTE OF LOGIC 

t 

X Superman exists. 

W Superman is willing to prevent evil. 

A Superman is able to prevent evil. 

M Superman is malevolent. 

I Superman is impotent. 

E Superman prevents evil. 


In terms of these propositions and the logical connectives, the argument becomes: 


( 

((WhA)=>E) 

(M)=>/) 

A 

((-4*0 =* M) 

A 

(-*) 

A 

(X =» -<J v M)) 
) 


bX) 


\ 

If Superman were willing and able to prevent evil, he would do so. 
If he were unable to prevent evil, he would be impotent. 

If he were unwilling to prevent evil, he would be malevolent. 
Superman does not prevent evil. 

If Superman exists, he is neither impotent nor malevolent. 
Therefore, 

Superman does not exist. 


An argument is valid if it is impossible for the premises to be true and the conclusion to be false. 
Suppose P and Q are propositions; then: 


-» P is true if P is false, and false if P is true. 

P A Q is true whenever both P and Q are true. 

P V Q is true if either P or Q (or both) are true. 

P => Q is true if whenever P is true, then Q is true also. By convention 
we regard P => Q as being true if P is false. In fact, it is 
common to regard P => Q as equivalent to -»P V Q ; however, 
some philosophers called intuitionists disagree with this treatment 
of implication. 

P & Q is trueifP and Q are either both true or both false. In factP Q i 
is equivalent to(P=» Q)a(Q=> P). 

A statement of the form ( if A then B\ written A => B> is called an implication ; A is called 
the antecedent and B the consequent. 


2.1.1 Tautologies and Counterexamples 

Let us consider the following valid argument: 

If an algorithm is proven, then it is reliable. Therefore, an algorithm cannot be both 
proven and unreliable. 

If we let P denote the proposition that an algorithm is proven, and R denote the proposition that 
an algorithm is reliable, then the argument can be formalised as 

(P=> £)=»-,(/> a-.P) 

We can verify that the argument is valid by constructing a truth table for it as follows: 
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The implication in the argument is true whatever the values of P and R. A tautology is a 
propositional form that is true whatever assignment of true or false is given to each of its constituent 
simple propositions. An argument is an implication in which the premises form the antecedent 
and the conclusion forms the consequent. Now we see that an argument is valid if and only if it is 
a tautology. 

The following is an example of an invalid argument: 

If an algorithm is proven, then it is reliable. Therefore, an algorithm is proven or it is 
not reliable. 

This argument can be formalised as 


(P =► R) =* (P V ifl) 

Once again we can construct a truth table, this time to show that the argument is not valid. 


P R 

( p *R) 

=> 

< 

j 

5 

T T 

T 

T 


F T 

T 

F 

F F F 

T F 

F 

T 

T T T 

F F 
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T 
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A counterexample to the argument is given by P being false and R being true. 

2.1.2 Equivalences 

Truth tables work well for establishing the validity of arguments if the number of simple propo¬ 
sitions is small; otherwise, they are impractical as the number of cases to consider grows expo¬ 
nentially with respect to the number of propositions. Two alternative techniques for manipulating 
logical formulas are the use of known equivalences between formulas, and the application of rules 
of inference. ^ 

Consider the two equivalent definitions of a valid argument: (P =» Q) and -»(P A ->Q). In 
other words, 

(P=*Q)«MPA^Q) 

is a tautology. We call a tautology of the form P & Q an equivalence , written P = Q. 

There are many equivalences between formulas in logic; some of die common ones are given 
below. 

1. Constants 

(P V true) = true (P V false ) = P 

(P A true) = P (PA false) = false 

(true => P) = P ( false => P) = true 
(P => true) = true (P => false) = ->P 

2. Law of Excluded Middle 

P V (~>P) = true 

3. Law of Contradiction 

P A (-«P) = false 
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4. Negation 

-.-.PssP 

5. Idempotency 

(PVP) = P 
(PAP) = P 

6. Implication 

(P=*.Q) = hPVQ) \ 

(P=>Q) = hQ*^P) 

7. Associativity 

PV(QVA) = (PVQ)VP 
PA(QAP) = (PAO)AP 

8. Commutativity 

(P A Q) = (Q A P) 

(PVQ) = (QVP) 

9. Distributivity 

PA(QVP) = (PAQ)V(PAP) 

P V (Q A P) = (P V Q) A (P V P) 
p => (g v P) = (P =» Q) v (P =* P) 
p=^(Qap) = (p=>o)a(p=>p) 

PV(Q=^ P) = (PVQ)=>(PVP) 

10. De Morgan s Laws 

-i(P V Q) = -«P A ~>Q 
-i(p a g) = -i P V -.Q 


2.1.3 Rules of Inference 

In order to produce a formal proof that something is true, one typically needs to be able to deduce 
new propositions from existing ones in a sound way. This is done by means of rules of inference. 
If the conclusion of an argument can be derived from the premises by a sequence of steps using 
equivalences and rules of inference, then the argument is guaranteed to be valid. 

One convention for depicting a rule of inference is to list the premises of the rule above a 
dividing line which has the conclusion or inference below it Consider the rule 

P Q 

P A Q 

which says that if it is possible to prove P and it is possible to prove Q, then it is valid to infer the 
conjunction P A Q. This is known as the A-introduction rule. Another well-used rule of inference 
is the ^-elimination rule, more commonly known as modusponens, 

P P=>Q 

5 

which states that Q follows from a proof of P and a proof of P =* Q. A complete set of 
introduction and elimination rules is given below. 
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Introduction rules 

Elimination rules 

A-I: 

PQ 

A-E: 

PaQ paq 

PAQ 

p a 

v-I: 

P Q 

V-E: 

Ifl IQ] 

PVQ R R 

R 

PvQ W 

=►-1: 

[P] 

Q 

=»-E: 

P P^>Q 
- 71 - 


P =$■ Q 



-»-I: 

[P] 

false 
i P 

-.-E: 

P -«P false 

false P 


The notation [P] is read as “assuming P is true” so that the V-elimination rule reads as follows: 
if only two cases P and Q need be considered, and if R follows from assuming P and also from 
assuming Q, then it is valid to infer R in all cases. 

Example 2.1.1 Let us now consider a complete formal proof, in this case one direction of one of 
the distributivity laws. We will prove 

P A(Q V R) => (P AQ)V {P A R) 

The proof proceeds as follows. 

Assume 1. P A (Q V R) 

2. P 

3. QVR 

Assume 4. Q 

5. PAQ 

6. (PAQ)\J(PAR) 

Assume 7. R 

8. PAR 

9. (PAQ)M(PAR) 

10. (P A Q) V (P A R) (3,4, 6, 7,9, V-E) 

11. P A (Q V R) =* (P A Q) V (P A R) (1,10, =»-I) 


0,'A-E) 

d.A-1) 


' (2,4,A-I) 

(5,V-I) 


(2, 7, A-I) 
(8, V-I) 


□ 


2.2 The Predicate Calculus 

For simplicity, only a fragment of this language will be used. Things like: 

true, false , a? = 1, r<y, i = r + (yxg) 
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are examples of atomic statements. Statements are either true or false. The statement true is 
always true and the statement false is always false. The statement x - 1 is true if the value of x is 
equal to 1. The statement x < y is true if die value of x is less than the value of y. The statement 
x = r + (y x q) is true if the value of x is equal to the sum of the value of r with the product of y 
and q. 

Thus, the predicate calculus deals with relative truths, that is, statements whose truth depends 
on the values of variables such as x and y. We say that x < y is predicated on x and y, or the 
relation x < y is a predicate. 

Statements are built out of terms like: 

X, 1, r, y, r + (rf[xq), yxq 

Terms denote values such as numbers and strings, unlike statements which are either true or false. 
Some terms, like 1 and 4 + 5, denote a fixed value, whilst other terms contain variables like x, 
y, z, etc. whose value can vary. We will use conventional mathematical notation for terms, as 
illustrated by the examples below: 

x, y, z y 

1, 2, 325, 

-x, -(x+1), (x x y) + z, 

v/(l+s), x!, sin(x) 

The statements true and false are atomic statements that are always true and false respectively. 
Other atomic statements are built from terms using predicates. Here are some more examples: 

odd(x)y prime( 3), x = 1, (x + l) 2 > x 2 

The predicates above are odd and prime , along with = and > which are examples of infixed 
predicates. The expressions x, 1,3, x + 1, (x + l) 2 , x 2 are examples of terms. 

Compound statements are built up from atomic statements using the same logical operators as 
in the propositional calculus. Examples of statements built using the connectives are: 

odd(x) V euen(x) x is odd or even. 

i(pnmc(x) ^ odd(x)) It is not the case that if x is prime, 
then x is odd. 

x < y => x < y 2 If x is less than equal or equal to 

y, then x is less than or equal to 
V 2 - 

To reduce the need for brackets it is assumed that binds more strongly than A and V, which 
in turn bind more strongly than => and <$. For example: 

-ip A Q is equivalent to (-> P) A Q 
P At? => R is equivalent to (P A Q) => R 
p a Q & -<12 V S is equivalent to (PAQ)& ((-i R ) V 5) 

The value of a variable x is called the state of x, for example, x might have value 1. The set 
of all possible values for x, such as the set of integers, for example, is called the state space of 
x. From now on we will assume that all variables range over the integers unless otherwise stated. 
The state of a program is the state of all its variables. When a predicate is true in a given state, we 
say that the state satisfies the predicate. 

Example 2.2.1 The program state given by (t = 2, j = 3) satisfies the predicate * < j, while 
the state (* = 2, j = 2) does not. □ 

When no state satisfies predicate P, then P is said to be unsatisfiable. On the other hand, if 
all states satisfy P, P is said to be valid. 

Example 2.2.2 The statement (i < j) A (j < i) is unsatisfiable since there are no two integers 
for which it is true. The statement (i < j) => (i < j) is true for all integers i and j; it is therefore 
valid. □ 
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2.2.! Set notation 

We will often find it useful to use set-former notation which is of the general form 

{variables: predicate}. 


Example 2.23 The set 


{*: * > 0 } 


is the set of all integers i such that * is at least 0. The set 


{«. j:«< i) 

is the set of pairs of integers i,j such that i is less than j. □ 

These sets identify a subset of a universe of values, for example, the set of all integers, or the 
set of all pairs of integers. The universe of integers can be written as 


{*: true}, 


while 


{*: false} = 0. 

If P is predicated on s, then we can show that {i : P(i)} is empty by showing that P(i) is 
unsatisfiable, that is, P(i) = false. 


2.2.2 Logical Quantifiers 

We would like to be able to make statements such as “every element in the set has the property 
that...” or “there is some element in the set having the property..In order to do so, we need 
operators called quantifiers. 

Universal quantifiers 

The universal qualifier is denoted by V and is pronounced “for all.” Consider the statement 

V(i: 0 < i < n : a[i] > 0). 

This says that for all (integers) t, such that i is between 0 and n - l, a[t] is positive. The bracketed 
expression describes a set followed by a predicate on that set The variable t is a bound variable 
and the set {t: 0 < i < n} is the range of the bound variable. 

Example 2.2.4 The statement 


V(*: 0 < i < n : a[» - 1] < a[i]) 
states that the elements of array a are stored in increasing order. □ 

The range of a bound variable is omitted if it is true. For example, in 


V(i:: t x 0 = 0) 


the multiplication of an arbitrary value by 0 always yields 0. As before, the type of i is implicitly 
assumed to be integer 
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Existential quantifiers 

The existential quantifier is denoted by 3 and is pronounced “there exists.” Consider the statement 

3(t: 0 < t < n : a[i] = x). 

This says that there exists an (integer) i> such that i is between 0 and n - 1 and <*[*] equals x. As 
with V, there are two forms of 3: 

3 (v:R: P) 

read “there exists a v in the range R such that P, and 

3(»:: P) 

read “there exists a v such that P,” where the range of v is implicitly the type of v. Note that the 
equivalences 

3(t>: R : P) = -nV(v :R:-^P) 

and 

V(v : R : P) = -i3(u : R : -P) 

exists between sentences involving quantifiers. 

We have already seen an example of a bound variable. For instance, in Q(i: R(i): P(i)) 9 
variable t is bound to the quantifier Q. Those occurrences of a variable not bound to a quantifier 
in some expression R are said to be free in R. For example, in 

3(r :: x = y x r) 


r is bound while x and y are free. 


|— r v' 5 if ' * 6/bil*™ tyc 

(= - *• *^5 d v ' + '-V 


Chapter 3 


Proof Rules for Programs 


In this chapter we will be concerned with how to prove that a given program is correct with respect 
to its specifications. The proofs that we generate will be formal proofs based on manipulating 
assertions by means of rules of inference. We will use rules of inference that are specific to 
the constructs in our programming language, one rule per construct. These rules were originally 
proposed by Hoare in [1]. 

Since the proofs we generate are based essentially on the manipulation of symbols according 
to fixed rules, they can become long and tedious. On the other hand, this also means that such 
proofs can be mechanised to a laige extent, so that the tiresome details can be left to a computer 
program to figure out Our reason for covering the rules is so that one can appreciate the logical 
foundations of program verification systems, and that for describing a number of examples in 
detail is so that one can see the steps such a verifier would have to take. 


3.1 The Assignment Statement 

The simplest proof rule for programs is that associated with assignment statements. It is referred 
to as an axiom because it does not depend on anything else being proved, that is, it is always true 
for any assignment statement. 


P[eA>] 


Assignment Axiom 
h {P[e/v]}v:=e{P} 



In the assignment axiom, v is a variable, e is an expression, and the notation {P[e/v]} means 
that e is substituted for v wherever it occurs in P. Notice that this implies that one usually works 
backwards from P to P[e/v], 

Example 3.1.1 A couple of trivial examples follow: 


{y > 0} x := y {x > 0} 


{x > 0} x := x + 1 {x > 0} 

Note that in the second example we have used the fact that z + l>0 = z>0.Q 
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* 

The following two rules are used to manipulate specifications, allowing us to match up parts 
of a proof of correctness (as we shall demonstrate later). Essentially the rules say that we can 
always strenthen the precondition and weaken the postcondition of a specification. 


Precondition Stengthening 
hP=*P' 

w 


Precondition P is stronger than precondition P', so P describes fewer states than P': any 
state satisfying P also satisfies P'. So if {P / } S {Q} is valid and P =» P / , then it is valid to infer 
{P} S {Q}. The analogous rule for postconditions is postcondition weakening. 


Postcondition Weakening 

M P)S{Q '} 

hQ'=*Q 

FPf5W 


Postcondition Q is weaker than postcondition Q ; , so Q describes more states than Q': any 
state satisfying Q' also satisfies Q. In some texts, the above two rules are called the consequence 
rules . 

Example 3.1.2 Consider the specification 

{* > 0} i := i +1 {» > 0}. 

The precondition {» > 0} is stronger than {* > 0), so using the precondition strengthening rule 
we can derive the specification 

{* > 0} i := i + 1 {i > 0}. 

Since {t > 0} is weaker than {» > 0}, we could also derive 

(t > 0} i := i + 1 {i > 0} 
by the postcondition weakening rule. □ 


3 2 Sequences of Statements 

The next rule, the rule of sequential composition , is used for combining specifications about 
individual program statements into specifications for sequences of statements. 
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Figure 3.1: The rule of sequential composition 


Proof Rule For Sequential Composition 

*-{*>}* {Q } 

»- «}*{*} 

t {py^sUky- 


To paraphrase the rule: if executing S\ with precondition P guarantees postcondition Q, 
and executing S 2 with precondition Q guarantees postcondition R , then executing Si;S 2 with 
precondition P guarantees postcondition R. Diagrammatically this can be visualised as shown in 
Figure 3.1. 

Example 3.2.1 Let us give a formal proof of correctness of our routine for exchanging the values 
of variables s and y. 

{x = xo A y = yo} 

.BEGIN t := x; x :=y; y := t END 
{x = y 0 A y = so} 

Working backwards, the proof proceeds as follows. First we obtain a precondition for y s - t 
using the supplied postcondition along with the assignment axiom: 

{* = z 0 A x = yo} 

y s* t 

{s = y 0 A y = x 0 } 

Next we use this precondition as the postcondition for x : = y, and once again apply the assign¬ 
ment axiom to obtain a precondition for this statement: 

{t = s 0 A y = y 0 } 
x := y; 

{t = so A s = yo} 


Now we can combine these two results using the rule of sequential composition: 

{t = s 0 A y = yo} 

BEGIN x ;= y; y := 

{s = y 0 A y = s 0 } 


t END 
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Using the above precondition as the postcondition for t : = x, we obtain the precondition for 
this statement using the assignment axiom: 

{x = x 0 A y = yo} 
t :=x; 

{y = yo A t s *o} 

Since this precondition is the same as the original, the result follows from the above two steps by 
one more application of the rule of sequential composition: 

{x = s 0 A y = yo} 

BEGIN t :=x? x :=y; y := t END 
{s = y 0 A y = s 0 } 

The may seem like an extremely laborious way of proving a trivial result. Nevertheless, as we 
have stated before, these are the kinds of steps an automated verifier would have to take. In 
addition, as a result of going through the above, we will be better equipped to tackle less obvious 
results. □ 


33 Conditional Statements 

We have now seen two proof rules: the assignment axiom and the rule of sequential composition. 
In order to prove results about programs in our simple language that do not contain loops, we 
need to have proof rules dealing with conditional statements. Since there are two types of such 
statements, we have two proof rules, a rule for one-sided conditionals and a rule for two-sided 
conditionals. 


Proof Rule For One-Sided Conditionals 

h {PAB}S{Q} 

I- Pa -*b =$ Q 
I- {P} IF # THEN S {Q} 


This rule can be paraphrased as follows: if executing S with precondition P A B guarantees 
postcondition Q, and it can be proved that P A => Q, then executing IF B THEN S with 
precondition P guarantees postcondition Q. In other words, we have to show that if we start with 
die program in a state satisfying P, then whether we execute S or not the program ends up in a 
state satisfying Q. Diagrammatically this can be represented as shown in Figure 3.2. 

The proof rule for two-sided conditional statements is similar of course, except that now we 
have to consider statement Si when B is false. 


Proof Rule For Two-Sided Conditionals 

y- {P A B} St {Q} 
\-{PA^B}S 2 {Q} 

h {P} IF B THEN Sy ELSE 5*2 {Q} 
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This rule can be paraphrased as follows: if executing Si with precondition P A B guarantees 
postcondition Q , and executing S 2 with precondition P A ->B guarantees postcondition Q t then 
executing IF B THEN S 1 ELSE S 2 with precondition P guarantees postcondition Q. In other 
words, we have to show that if we start with the program in a state satisfying P f then no matter 
which part of the conditional statement is executed the program ends up in a state satisfying Q. 
Diagrammatically this can be represented as shown in Figure 3.3. 



Example 33.1 Let us now consider an example in which we need to use these proof rules, namely 
the example from Section 1.2 which determines the maximum of three integers. 

{true} 

IF i <= j 

THEN IF j < k THEN m := k ELSE m := j 

ELSE IF j < k THEN m := k ELSE m := i 

{m > * A m > j A m > k] 

The following is a formal proof of correctness of the above program fragment. For notadonal 
convenience, let us denote the first nested iF-statement as Si and the second as S 2 . Thus, the 
above statement is IF i <= j then S\ else S 2 . It makes sense to decompose the proof 

into three parts: (1) find a precondition for Si, (2) find a precondition for S 2 , and (3) prove the 

overall specification using die rule for two-sided conditionals. 

Clearly, £1 is only executed when i < j, so we begin by attempting to prove 
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{* <j}Sl{m>iAm>j/\m> fc). 

In order to prove this, we will need to work backwards finding preconditions for each of the 
components of the conditional statement 5[, and then use the role for two-sided conditionals. 
First, we obtain a precondition form := k using the assignment axiom. 

{k > i A k > j] m : = k {m > t A m > j A m > k} (1) 

Then using the assignment axiom again we obtain a precondition for the ELSE-part of Si . 

{j > * A j > k} m : = j {m > t A m > j A ri > k] (2) 

As an aside, notice that if we were using the incorrect postcondition of Section 1.2 in which 
m > j, we would derive an unsatisfiable precondition at this point, one in which j > j. This 
would immediately tell us that our postcondition was incorrect. 

In order to have the assertions in the correct form to apply the role for two-sided conditionals, 
we will have to strengthen each of the preconditions in (1) and (2). Using the normal roles of 
inequalities, we have die following two implications. 


(i < j A j < k) => (k > i A k > j) (3) 

(i < j A j > k ) => (j > i A j > k) ^ (4) 

We now apply the precondition strengthening role to (1,3) and (2,4), thereby deriving the following 
two specifications. 

{* < j A j < k) m : = k {m > i A m > j A m > k} (5) 

{* < j A j > k] m : = j {m > t A m > j A m > k) (6) 

Now (5) and (6) are in the form in which the two-sided conditional role can be applied directly to 
obtain the desired result 

{* < j} Si {m > * A m > j A m > k } (7) 


Following steps similar to those above, we can derive an analogous proof for a valid precondition 

for 52. 


{j < *} 52 {m > * A m > j A m > k} (8) 

We cannot apply the two-sided conditional role directly to (7) and (8) because {j < t} is not the 
negation of {* < j}. Nevertheless we can modify (8) by using the feet that j < i =* j < i and 
precondition stengthening to yield the following. 

{j <i}S 2 {m>iAm>j Am> k} (9) 

Now applying the two-sided conditional role to (7) and (9) proves that our original program 
Augment is correct with respect to its pre- and postconditions. □ 


3.4 While Statements 

In order to prove the correctness of a WHlLE-statement, we need to find an assertion that is 
invariant , that is, the assertion is true each time around the loop. This is veiy similar to finding the 
correct inductive hypothesis for a proof by mathematical induction. In feet, the similarity extends 
further in that just as finding the correct inductive hypothesis is usually the most difficult part 
of a proof by induction, finding a strong enough loop invariant is usually much harder than the 
subsequent proof of correctness of the loop. For this reason, most program verification systems 
require that the user supply an invariant for each loop in a program, after which the system will 
ensure that each is indeed invariant and will attempt to complete the proof of correctness. 
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Example 3.4.1 Consider the following program which adds the sum of a sequence of integers to 
a variable s. 

WHILE (ion) DO 
BEGIN 

s := s + i? 
i := i + 1 
END 

An invariant I for the above loop is s = i * (» - l)/2, which looks rather similar to the formula 
one would use in the inductive hypothesis in a proof by induction of the formula for the sum of 
an arithmetic progression. The fact that / is an invariant means that if / is true before the body 
of the loop, say S, is executed, then it is true afterwards. In other words, {/} 5 {/} is a correct 
specification. □ 

Up until now, all programs we have considered have been guaranteed to terminate since they 
contained no loops. This means that proofs of partial correctness were all that were required; 
partial correctness always implied total correctness. Now that we are considering loops, the 
situation changes. For instance, the program given in Example 3.4.1 above will not terminate if 1 
starts off being larger than n. The proof rule for WHILE -statements we consider is one for partial 
correctness, that is, it assumes that the given loop terminates. A separate proof of termination is 
necessary to show the total correctness of each loop. We first consider the proof rule for partial 
correctness. 


Proof Rule For While Statements 


h {/ A B] S {/} 

I- {/} WHILE B DO S{I 


This rule states that if we can pfOVe that / is left unchanged by a single execution of S (in 
which case B must also be true in order for'5 to be executed), then it is unchanged after the while 
loop terminates (in which case B will be false). 

We are more likely to find ourselves facing the task of proving that {P} WHILE B DO S {Q} 
is valid, where P and Q are general assertions. In this case, we have to (1) find an invariant I 
for the loop, (2) show that P => /, and (3) show that / A -«£ => Q. Then the desired result 
follows from precondition strengthening, postcondition weakening, and the proof rule for while 
statements. Effectively, we have derived another proof rule for while statements. 


Derived Proof Rule For While Statements 

h P=>I 
h {/ A B} S {/} 
h / A -i B => Q 
h {P} WHILE B DO £{<J} 


The first premise states that I is true before the loop executes (similar to the basis in mathemat¬ 
ical induction), the second states that / is an invariant (similar to the induction step in mathematical 
induction), and the third states that, on termination of the loop (when I is still true and B must be 
false), Q is true. A visual representation of this rule is shown in Figure 3.4. 
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Figure 3.4: The derived rule for while statements 


Example 3.4.2 Consider the while loop given in Example 3.4.1 and repeated below. 

WHILE (i <> n) DO 

BEGIN s : = S + i; i : = i + 1 END 

Suppose that we want to prove that the loop is partially correct with respect to the precondition 
0 P = (»==0Aa = 0) and the postcondition Q = (s = n *(n - l)/2). There are four steps to 
follow before we can use the derived proof rule for while statements. First, we think up a loop 
invariant /, which in this case is s = i * (i - l)/2. Next, we prove that I is true before the first 
iteration of the loop, that is, we prove that P ^ /. This is straightforward since if P is true, both 
t and 8 are zero and / reduces to 0 = 0 which is clearly true. 

Thirdly, we have to show that I is indeed an invariant for the loop by proving that {/ A B] a 
;= s + i; i ;= i + 1 {/}. In other words, if the program is in a state satisfying /(and B 
if the body of the loop is to be executed) before execution of the body of the loop, then the program 
will be in a state which still satisfies I after a single execution of the loop body. This can be done 
as before using two applications of the assignment axiom, the rule of sequential composition, and 
die precondition stengthening rule. Working backwards, we get the following precondition for i 
5*1 + 1 . 

{s = (i + 1) * i/2} i : = i + 1 {5 = t * (i - i)/2} 

Using this precondition as a postcondition for s := s + i, we obtain the following precondition 
for the body of the loop. 

{s + * = (t + 1 ) * i/ 2 } s := s + i {s = (* + 1 ) * i/2) 

By simplifying this precondition we get exactly /. Since / A B => /, the result follows by 
precondition strengthening. 

The final step is to show that Q is a valid postcondition after the loop terminates. For this we 
need to prove that / A ->B Q. Since is just i = n, / A -<£ simplifies to exactly Q, namely 
3 = n* (n - l)/ 2 . 

We conclude that the loop is partially correct with respect to precondition P and postcondition 

Note that in the above example we have still not proved that the while loop is (totally) correct 
with respect to its specifications. Indeed even if i and s both start off as zero, if n is negative to 
begin with, the loop will not terminate and therefore is not totally correct. Proving termination is 
the subject of the next section. 
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3.5 Termination 

In order to show that a while statement is totally correct we need to show both that it is partially 
correct using the rules defined in the last section and that it terminates. For a program to be totally 
correct, every loop in the program must terminate. In this section, we consider how such proofs 
can be formalised. 

One way of checking that a loop is guaranteed to terminate is to discover an integer function 
t of the program variables such that (1) the value of t is decremented by each execution of the 
loop and (2) as long as the loop has not terminated, the value of t is guaranteed to be greater 
than zero. Finding such a function and proving the atx)ve two results will then ensure that t must 
eventually be decremented to a value which is less than or equal to zero and hence that the loop 
must terminate. The function t is called the bound (or variant ) Junction. 

Given a while statement with Boolean condition B and body S along with an invariant I and 
bound function t, the formal statements corresponding to the above two conditions which have to 
be proved are as follows. 

1. / A B => (t > 0) 

2. {/A £}*':=*; S{t <*'} 

The first of these shows that if the loop has not terminated (since B is still true), then the value of 
t must still be positive. In the second statement, t* is simply being used as a temporary variable 
to hold the value of t before the body of the loop executes. If the second statement can be proved 
valid, then each iteration of the loop decrements the value of t. 

Example 3.5.1 Determining the bound function is often easy, particularly when there is an explicit 
loop variable which is being incremented or decremented. Consider once more the program of 
Example 3.4.1. 

WHILE (ion) DO 

BEGIN s := S + i; i := i + 1 END 

Here what is intended is that i is incremented until it becomes equal to n. So the bound function 
is simply t = n - which is the number of iterations the loop still has to perform at any stage. 
However; with /being a = **(i- l)/2we cannot show that /A B =» (t > 0), the reason of course 
being that n could start off being less than i. This should alert us to the feet that something is 
wrong. What we need to do in order to succeed with the above proof is to strengthen the invariant 
to include the term i < n, that is / = (i < n A a = i * (i - 4)/2). This will also necessitate 
strengthening the original precondition P in the same way to be able to prove that P => I. This 
corresponds to our intuition, since the precondition now states that the loop will be totally correct 
only if the program starts in a state in which i < n. 

Now we can prove the two conditions necessary for termination. For the first we have to show 
that / A B => (f > 0). Looking at the formulae for I and B , we see that / A B =» i < n. This in 
turn is equivalent to stating that n - i > 0. Since n - i is t , we have shown that t > 0 as required. 

The second condition requires us to prove that {/ A B} t' := t\ S {t < t'} is a correct 
specification. Using the fact that t = n - i we obtain a precondition for S in the usual way. 

{n - (i + 1) < *'} i : = i + 1 {n - i < t'} 

{n - (i+1) < f'} s := s + i [n - (i + 1 ) < t'} 

Using this precondition as a postcondition for t' := t, we obtain the precondition {n-(*+1) < *}. 
Substituting n - i for t, we obtain a condition which is always true and therefore certainly implied 
by I A B. In other words, t is decremented each time around the loop irrespective of whether I t^B 
is true or not We have thus shown that the loop always terminates given die stronger precondition 
P. □ 

We conclude this chapter with some examples of complete proofs of (total) correctness. 
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3.6 Correctness Proofs 

We provide proofe of (total) correctness for two sample programs in this section. Once again we 
do not expect programmers to go through this process for each module of code they write. Current 
programming methodology, however, does encourage the use of pre- and postconditions for each 
module, as well as specification of invariants for each loop in a program. As stated previously, 
these provide useful documentation as well as helping the testing process if the compiler being 
used offers a facility for checking assertions automatically. The hope is that as program verification 
tools become more widely available they will use these assertions in the automatic verification of 
portions of code. / 

Example 3.6.1 Consider the following program which sets the variable i to the highest power of 
2 that is less than or equal to the value of the variable n. 

P : {n > 0} 
i := 1; 

WHILE (2 * i <= n) DO 
i := 2 * i? 

Q : {(0 <t<n<2**)A 3 (p:: t = 2 P )} 

There are a number of steps involved in proving the above program correct with respect to P and 

Q- 


1. Find an invariant I for the loop: a correct invariant is 

/ = (0 < s < n A 3(p:: i = 2 P )). 

Also find a bound function i for the loop: n - t will suffice. 

2. Show that I is true before the loop, that is, {P} i : = 1 {/} is valid. Substituting 1 for t 
in / we get 

/(1) = 0 < 1 < n A 3(p:: 1 = 2 P ) 

= 1 < n A true 

= n > 0 
= P 

3. Show that I is an invariant, that is, {/ A B} i : = 2 * i {/}. First find a precondition 
Pi for i : = 2 * i. By die assignment axiom, this is 

Pi = (0 < 2 * t < n A 3(p:: 2 * t = 2 P )). 

Now if we can show that / A B => P|, then the result follows by the precondition strength¬ 
ening rule. For ZAP we get 

0 < t < n A 3(p :: * = 2 P ) A 2 * i < n. 

Combining the first and last terms while noting that if there is a p satisfying i = 2 P then 
there is a p satisfying 2 * t = 2 P (namely one more than the first p), we can see that this does 
imply precondition Pi. 

4. Show that, on termination of the loop, the program will be in a state satisfying Q, that is, 
prove that / A => Q. In fact, / A gives us a formula equivalent to Q; namely 

0 < i < n A 3(p :: * = 2 P ) A 2 *i> n. 
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5. Show that the bound function t = n—i is positive whenever the body of the loop is executed, 
that is, / A B => t > 0. 

I = 0 < i < n A 3(p :: 1 = 2 P ) A 2 * i < n 
=> 0 < i < n A 2*i < n 
n - i > 0 

6 . Show that each loop iteration decreases t , that is, prove that 

{/A B} t' := n - i; i := 2 * i (n - * < f'} 

is a valid specification. Applying the assignment axiom to i : = 2 * i, we get the 
precondition {» - (2 * i) < f'}. Now applying the assignment axiom to t' := n - 
i, we get precondition {n - (2 * i) < n - i] which is exactly {i > 0}. It is clear that 
/ A B => i > 0, so the result follows by the rule of sequential composition and precondition 
strengthening. 

Steps (1) to (4) show that the program is partially correct with respect to P and Q, while steps (5) 
and (6) show that the program terminates. □ 

Example 3.6.2 Now consider the following program which finds a value for variable k such that 
a [k] is the maximum value of the array a [0 :n-1]. 

P : {n > 0} 
i := 1; k := 0; 

WHILE (i < n) DO 
BEGIN 

IF a [i] > a [k] THEN k := i; 
i := i + 1; 

END 

Q : {V(j : 0 < j < n : a[k] > a[j])} 

Rather than referring to each of the assertions and statements of the program explicitly all the 
time, let us give them names as follows. 

m 

Sn 52? ^ 

WHILE Bi DO 
BEGIN 

IF Bi THEN 53? 

54? 

END 

{Q } 

As before, there are a number of steps to follow. We will prove some of them, leaving the others 
as exercises. 

1. An invariant / for the loop is 

0 < t < n A V(j : 0 < j < i : a[&] > a[j]) 

which says that k is the array index of the largest element found so far (that is, between 
a [0] and a [i - 1] ). The bound function t is n - i as before. 

2. Prove that / is true before the loop executes, that is, prove that {P} Si ; 52; {/} is correct. 
We leave this as a straightforward exercise. 
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3. Prove that I is an invariant of the loop, that is, prove that 

{/ A Bi} IF B 2 then S 3 ; S 4 { 1 } 

is correct This step itself is best broken down into two steps: (a) find a precondition Pi for 
S 4 , and (b) show that {/A Pi} IF B 2 THEN S 3 {Pi} is correct. 

(a) Precondition Pi is obtained by substituting i +1 for t in I (according to the assignment 

axiom) which yields ^ 

Pi = (0 < 1 4-1 < n A V(j : 0 < j < i + 1: a[&] > a[j])). 

(b) According to the proof rule for one-sided conditionals, we need to prove (i) / A Pi A 
1 P 2 => Pi, and (ii) {/ A Pi A P 2 } k : = i {Pi}. 

i. The proof proceeds as follows: 

/ A Pi A -1P2 = 0 < t < n A V(j : 0 < j < i : a[k] > a[j]) A i < n 
A a[i] < a[fc] 

= 0 < i + 1 < n A V(j : 0 < j < i : a[fc] > a\j]) 

A a[A] > a[i] 

s Pi 

ii. First, find a precondition P 2 for k := i using postcondition Pi and the assign¬ 
ment axiom, that is, substitute i for k in Pi yielding 

Pi = (0 < 1 4- 1 < n A V(j : 0 < j < i + 1 : a[i] > a[i])). 

Next, show that / A Pi A B 2 =» P2. 

/ A Pi A B 2 = 0 < i < n A V(j : 0 < j < i: a[k] > a[j]) A t < n 
A a[t] > a[k] 

= 0 < * -f 1 < n A V(j : 0 < j < i -j- 1 : a[t] > a\j]) 

= Pi 

We conclude that / is an invariant. 

4. Prove that Q is true after the loop terminates, that is, prove that I A -<Pi Q. 

/ A -.Pi = 0 < t < n A V(j : 0 < j < i : o[fc] > a[j]) A t > n 
= 0 < i = n A V(j : 0 < j < n : a[fc] > a[jj) 

=> V(j : 0 < j < n : a[fc] > a[j]) 

= Q 


The above four steps have shown that the given program is partially correct with respect to 
precondition P and postcondition Q. We leave the two steps necessary to show termination as an 
exercise. □ 
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